home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_fj / text0028.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  2.9 KB  |  70 lines
  1. Hi,
  2.  
  3. I did get your email yesterday, but for some reason I forgot about it.
  4.  
  5. I guess it would be better to try to use the list from now on.
  6.  
  7. I'll try to make a digest of the discussions so far that will be sent to
  8. all new applicants to our list.
  9. Do you save all your email? If you do, I'd appreciate if you could resend
  10. it all to the list to make the digest compilation easier. Perhaps it'd be
  11. a good idea to edit out the stuff not related to BAD MOOD.
  12.  
  13. If you do not have your old email saved, I've probably got at least everything
  14. you sent to me around here somewhere.
  15.  
  16. Once the digest is compiled I'll announce the list on the atari newsgroups.
  17.  
  18. You have no objections to the list name? 
  19.  
  20. > is to code the game without thinking too much about optimisations. This 
  21. > part of code will come latter. Coz actually, we'll probably eliminate some
  22. > things that appear unusefull but that may be very important after. What do
  23. > you think of that. The second argument is that it's much easier to optimise
  24. > a code when it's finished, like that, we can see if the changes work or not.
  25.  
  26. Yes, I guess you're right. We should probably still do all the drawing using
  27. my direct method, since the other one is likely to be extremely difficult to
  28. debug. All the tables can of course be updated in any case.
  29.  
  30. I'll try to fix up the sources that way and send them to you.
  31.  
  32. > about it. In fact, I think that the DSP part must be the last part of the
  33. > code, coz it's when we'll see what takes the most machine time that we'll be
  34. > able to code it in the DSP.
  35.  
  36. Yes, unless it's very obvious that something _can't_ be done by the CPU in
  37. any reasonabale amount of time. If more people get involved it won't hurt
  38. to have several working on different implementations of the same thing.
  39.  
  40. > So if you could send me a cleaned big code, I would agree. In fact, these 
  41. > tables only takes 64k on 4 Megs, and they'll probably don't need to go in the
  42. > DSP, who knows ?
  43.  
  44. For the CPU the tables are small enough, but I'd be surprised if we can get
  45. any useful rendering speed with that alone. The tables are very deeply
  46. involved in the rendering process, so if that's done on the DSP, the tables
  47. will have to be there.
  48.  
  49. I do agree that it's best to go CPU only for the time being, though. An
  50. added benefit is of course that people with TTs, Medusas etc can use almost
  51. the same code.  :-)
  52.  
  53. > PS: Tell me when the mailist works.
  54.  
  55. It works already, just email to bad_mood@rand.thn.htu.se.
  56. Bertrand has now joined as well, so everything you post to the list will
  57. reach us all. You'll get a copy of your own email as well as it's currently
  58. set up, but I think that can be useful.
  59.  
  60. Regards,
  61. Johan
  62.  
  63.  
  64. -- 
  65.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  66.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  67.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  68.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  69.  
  70.